Method and system for the dynamic allocation of resources based on a multi-phase negotiation mechanism

ABSTRACT

A system and method for the dynamic allocation of resources based on multi-phase negotiation mechanism. A resource allocation decision can be made based on an index value computed by a selection index function. A negotiation process can be performed based on a schedule, a number of resources, and a price of resources. A user requesting a resource for a low priority task can negotiate based on the schedule, the user demanding the resource for a medium priority task can negotiate based on the schedule and/or the number of resources, and filially the user requesting the resource for a high priority job can successfully negotiate based on per unit resource price. The multi-phase negotiation mechanism motivates the users to be cooperative among them and improves a cooperative behavior coefficient and an overall user satisfaction rate.

TECHNICAL FIELD

Embodiments are generally related to resource allocation methods andsystems. Embodimetns are also related to service sharing and processmanagement applications. Embodiments are additionally related to theallocation of resources based on a multi-phase negotiation mechanism.

BACKGROUND OF THE INVENTION

Resource allocation is utilized in a number of applications and istypically employed to assign available resources in a cost effectivemanner. Resource allocation may be determined utilizing, for example,algorithms and computer programs applied to a specific domain toautomatically and dynamically distribute resources. Resource allocationis useful in a number of areas including, for example, service sharing,shared hosting platforms, and project management.

The project management domain involves the planning, organizing, andsecuring of resources in order to successfully complete specific projectgoals and objectives. In project management, resource allocationtypically includes the scheduling of activities and resources requiredwhile taking into consideration both the resource availability and theproject time. Resource allocation can thus involve the use of a largenumber of algorithmic solutions to allocate problems.

Demand patterns, however, may undergo permanent or seasonal variationsin demand during the life cycle of a process due to changes in, forexample, customer and user requirements. Additionally, changes in theexecution speed of particular processes may result as process operatorsbecome more proficient at their tasks or begin performing new types oftasks. As a consequence, a process may move into a state of sub-optimalperformance. Such changes can render the initial resource allocation ofproject sub-optimal, which can result in below-par performance of theintended process. The actual number of resources required may be higheror lower than the number initially allocated as a part of the projectmanagement process.

Conventional models for allocating resources include, for example, aneven resource distribution, a highest priority first, a shortest jobfirst, and a first come first serve. Such resource allocation modelseither focus on a system “fairness” or system throughput measurement.The “fairness” measure (e.g., a fairness index) can be calculatedutilizing Jain's fairness index and a max-min ratio. The Jain's fairnessindex is only efficient for a homogenous user demand (i.e., user havingsimilar demand and equal priority). The max-min ratio mechanism does notlead to precise evaluation of the fairness measure because it considersonly the maximum and minimum allocations while computing the fairnessmeasure.

For example, the even resource distribution approach is only efficientfor the homogenous user demand so that the resources can be allocatedevenly. The fairness measure of the even resource distributionallocation can be computed utilizing the Jain's fairness index asindicated in equation (1) as follows:

$\begin{matrix}{{f(x)} = \frac{\left\lbrack {\sum\limits_{i = 1}^{n}x_{i}} \right\rbrack^{2}}{\sum\limits_{i = 1}^{n}x_{i}^{2}}} & (1)\end{matrix}$

According to the definition of the Jain's fairness index f(x) ε [0,1],where value of 0 implies least fair and value of 1 implies maximum fair.Such fairness model can be applied to the user having similar demand anddoesn't yield high system throughput. The highest priority firstapproach offers a high throughput solution, however, it is not fair incases where R<<D where R represents total available resources and D isthe total demand of all the users. Similarly, the shortest job firstapproach and the first come first serve algorithm offers partiallyefficient solutions which are either fair or yield high throughput.Additionally, such prior art models either utilize a price negotiationor a demand negotiation based on single variable such as, for example,number of resources.

Based on the foregoing, it is believed that a need exists for animproved system and method for dynamically allocating resources based onmultiphase negotiation mechanism, as will be described in greater detailherein.

BRIEF SUMMARY

The following summary is provided to facilitate an understanding of someof the innovative features unique to the disclosed embodiment and is notintended to be a full description. A full appreciation of the variousaspects of the embodiments disclosed herein can be gained by taking theentire specification, claims, drawings, and abstract as a whole.

It is, therefore, one aspect of the disclosed embodiments to provide foran improved process management systems and methods.

It is another aspect of the disclosed embodiments to provide for animproved system and method for dynamically allocating resources based onmulti-phase negotiation mechanism.

The aforementioned aspects and other objectives and advantages can nowbe achieved as described herein. A system and method for the dynamicallocation of resources based on multi-phase negotiation mechanism isdisclosed. A resource allocation decision can be rendered based on anindex value computed via a selection index function. A negotiationprocess can be performed based on a schedule, a number of resources, anda price of resources. A user requesting a resource for a low prioritytask can negotiate based on the schedule, the user demanding theresource for a medium priority task can negotiate based on the scheduleand/or the number of resources, and finally the user requesting theresource for a high priority job can successfully negotiate based on perunit resource price. The multi-phase negotiation mechanism motivates theusers to be cooperative among them and improves a cooperative behaviorcoefficient and an overall user satisfaction rate. Such resourceallocation approach provides a Pareto optimal solution withoutimplementing market mechanisms and leads to high user satisfaction andretention rates.

The negotiation based on schedule with respect to each user can beperformed by considering a selection index, a user demand, and a demandschedule tuple. The user demand schedule represents the number ofresources required by the user within a specified time frame. An actualschedule can be analyzed and a new schedule can be offered to satisfythe user demand. The scheduling can be performed based on the selectionindex value and a higher priority is provided to a higher index value.The value of the total available resources can be determined based onthe user demand. The schedule which is closer to the actual schedule ofthe user is offered by the system in subsequent time steps. If thesystem is not able to satisfy the demands of the user, then the userwith the lowest selection index value can be removed and considered fornegotiation based on the number of resources.

The negotiation based on the number of resources can be performed byconsidering the selection index and the user demand tuple. A reductionfactor which determines the percentage reduction in the user requirementcan be determined so that the demand of the user can be fulfilled. Thevalue of the reduction factor can be chosen in such a way that a minimumresource allocation quantity is equivalent to a lowest unit of resource.The system enters into an iterative negotiation process with the user,where subsequent iterations offers number of resources closer to anactual user demand. If the system is not able to satisfy the demands ofthe user, then the user with the lowest selection index value can beremoved and considered for negotiation based on the price of resources.

The negotiation based on the price of resources can be performed byconsidering the selection index and the user demand tuple. A costfactor, which determines the new per unit price of the resource to beallocated to the user, can be set. The value of the cost factor can beincreased in each iteration and the process continues until the userdemand is equal to the total availability. With the increase in unitprice in successive iterations, the user can reduce the demand to 0(i.e., to quit the negotiation process). The user with low values of thebehavior coefficient can be considered as a greedy user and the userwith high values are considered as a cooperative user. The greedy userstend to be less flexible in the negotiation process, while cooperativeusers are more flexible in the negotiation process. As a result, thecooperative users lead to a more efficient resource allocation processand in order to motivate the users to be more cooperative the behaviorcoefficient value can be assigned to each user depending on the userbehavior. The user with higher values of behavior coefficient (i.e.,cooperative users) can have higher probability of selection in futureinteractions, as compared to the user with lower values of behaviorcoefficient (i.e., greedy users). The multi-phase negotiation providesan efficient solution to the resource allocation problems by increasingthe user satisfaction rate. The multi-phase negotiation mechanisms canbe implemented by a virtual broker in an ACS marketplace.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying figures, in which like reference numerals refer toidentical or functionally-similar elements throughout the separate viewsand which are incorporated in and form a part of the specification,further illustrate the present invention and, together with the detaileddescription of the invention, serve to explain the principles of thepresent invention.

FIG. 1 illustrates a schematic view of a data-processing system, inwhich disclosed embodiments may be implemented;

FIG. 2 illustrates a schematic view of a software system including adynamic resource allocation module, an operating system, and a userinterface, in accordance with the disclosed embodiments;

FIG. 3 illustrates a block diagram of a dynamic resource allocationsystem, in accordance with the disclosed embodiments;

FIG. 4 illustrates a high level flow chart of operation illustratinglogical operational steps of a method for dynamically allocatingresources based on multi-phase negotiation mechanism, in accordance withthe disclosed embodiments;

FIGS. 5-6 illustrate a graph depicting data indicative of percentage ofsatisfied users with respect to various resource allocation approaches,in accordance with the disclosed embodiments; and

FIGS. 7-8 illustrate a graph depicting data indicative of user waitingtime with respect to various resource allocation approaches, inaccordance with the disclosed embodiments.

DETAILED DESCRIPTION

The particular values and configurations discussed in these non-limitingexamples can be varied and are cited merely to illustrate at least oneembodiment and are not intended to limit the scope thereof.

The embodiments will now be described more fully hereinafter withreference to the accompanying drawings, in which illustrativeembodiments of the invention are shown. The embodiments disclosed hereincan be embodied in many different forms and should not be construed aslimited to the embodiments set forth herein; rather, these embodimentsare provided so that this disclosure will be thorough and complete andwill fully convey the scope of the invention to those skilled in theart. Like numbers refer to like elements throughout. As used herein, theterm “and/or” includes any and all combinations of one or more of theassociated listed items.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

As will be appreciated by one skilled in the art, the present inventioncan be embodied as a method, data processing system, or computer programproduct. Accordingly, the present invention may take the form of anentire hardware embodiment, an entire software embodiment or anembodiment combining software and hardware aspects all generallyreferred to herein as a “circuit” or “module.” Furthermore, the presentinvention may take the form of a computer program product on acomputer-usable storage medium having computer-usable program codeembodied in the medium. Any suitable computer readable medium may beutilized including hard disks, USB flash drives, DVDs, CD-ROMs, opticalstorage devices, magnetic storage devices, etc.

Computer program code for carrying out operations of the presentinvention may be written in an object oriented programming language(e.g., java, c++, etc.). The computer program code, however, forcarrying out operations of the present invention may also be written inconventional procedural programming languages such as the “c”programming language or in a visually oriented programming environmentsuch as, for example, visual basic.

The program code may execute entirely on the user's computer, partly onthe user's computer, as a stand-alone software package, partly on theuser's computer and partly on a remote computer or entirely on theremote computer. In the latter scenario, the remote computer may beconnected to a user's computer through a local area network (LAN) or awide area network (WAN), wireless data network e.g., WiFi, WiMax,802.11x, and cellular network or the connection can be made to anexternal computer via most third party supported networks (e.g. throughthe Internet via an internet service provider).

The embodiments are described at least in part herein with reference toflowchart illustrations and/or block diagrams of methods, systems, andcomputer program products and data structures according to embodimentsof the invention. It will be understood that each block of theillustrations, and combinations of blocks, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general-purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe block or blocks.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function/act specified in the block or blocks.

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions/acts specified inthe block or blocks.

FIGS. 1-2 are provided as exemplary diagrams of data-processingenvironments in which embodiments of the present invention may beimplemented. It should be appreciated that FIGS. 1-2 are only exemplaryand are not intended to assert or imply any limitation with regard tothe environments in which aspects or embodiments of the disclosedembodiments may be implemented. Many modifications to the depictedenvironments may be made without departing from the spirit and scope ofthe disclosed embodiments.

As illustrated in FIG. 1, the disclosed embodiments may be implementedin the context of a data-processing system 100 that can include, forexample, a central processor 101, a main memory 102, an input/outputcontroller 103, a keyboard 104, an input device 105 (e.g., a pointingdevice such as a mouse, track ball, pen device, etc.), a display device106, a mass storage 107 (e.g., a hard disk), and a USB (universal serialbus) peripheral connection 122. As illustrated, the various componentsof data-processing system 100 can communicate electronically through asystem bus 110 or similar architecture. The system bus 110 may be, forexample, a subsystem that transfers data between, for example, computercomponents within data-processing system 100 or to and from otherdata-processing devices, components, computers, etc.

FIG. 2 illustrates a computer software system 150 for directing theoperation of the data-processing system 100 depicted in FIG. 1. Softwareapplication 154, stored in main memory 102 and on mass storage 107,generally includes a kernel or operating system 151 and a shell orinterface 153. One or more application programs, such as softwareapplication 154, may be “loaded” (i.e., transferred from mass storage107 into the main memory 102) for execution by the data-processingsystem 100. The data-processing system 100 receives user commands anddata through user interface 153; these inputs may then be acted upon bythe data-processing system 100 in accordance with instructions fromoperating system module 151 and/or software application 154.

The following discussion is intended to provide a brief, generaldescription of suitable computing environments in which the system andmethod may be implemented. Although not required, the disclosedembodiments will be described in the general context ofcomputer-executable instructions such as program modules being executedby a single computer. In most instances, a “module” constitutes asoftware application.

Generally, program modules include, but are not limited to, routines,subroutines, software applications, programs, objects, components, datastructures, etc., that perform particular tasks or implement particularabstract data types and instructions. Moreover, those skilled in the artwill appreciate that the disclosed method and system may be practicedwith other computer system configurations such as, for example,hand-held devices, multi-processor systems, data networks,microprocessor-based or programmable consumer electronics, networkedPCs, minicomputers, mainframe computers, servers, and the like.

Note that the term module as utilized herein may refer to a collectionof routines and data structures that perform a particular task orimplements a particular abstract data type. Modules may be composed oftwo parts: an interface, which lists the constants, data types,variable, and routines that can be accessed by other modules orroutines; and an implementation, which is typically private (accessibleonly to that module) and which includes source code that actuallyimplements the routines in the module. The term module may also simplyrefer to an application such as a computer program designed to assist inthe performance of a specific task such as word processing, accounting,inventory management, etc.

The interface 153, which is preferably a graphical user interface (GUI),can serve to display results, whereupon a user may supply additionalinputs or terminate a particular session. In some embodiments, operatingsystem 151 and interface 153 can be implemented in the context of a“windows” system. It can be appreciated, of course, that other types ofsystems are possible. For example, rather than a traditional “windows”system, other operation systems such as, for example, a real timeoperating system (RTOS) more commonly employed in wireless systems mayalso be employed with respect to operating system 151 and interface 153.The software application 154 can include, for example, a dynamicresource allocation module 152 to constantly adjust the resourceallocation based on fairness, throughput, and multi-phase negotiationmechanism. The dynamic resource allocation module 152 can includeinstructions such as those of method 400 discussed herein with respectto FIG. 4.

FIGS. 1-2 are thus intended as examples and not as architecturallimitations of disclosed embodiments. Additionally, such embodiments arenot limited to any particular application or computing ordata-processing environment. Instead, those skilled in the art willappreciate that the disclosed approach may be advantageously applied toa variety of systems and application software. Moreover, the disclosedembodiments can be embodied on a variety of different computingplatforms including Macintosh, Unix, Linux, and the like.

FIG. 3 illustrates a block diagram of a dynamic resource allocationsystem 300, in accordance with the disclosed embodiments. Note that inFIGS. 1-8, identical or similar blocks are generally indicated byidentical reference numerals. The dynamic resource allocation system 300can be configured to include the dynamic resource allocation module 152to constantly adjust the resource allocation based on multi-phasenegotiation mechanism 360. The multi-phase negotiation mechanism 360further includes a user behavior computation module 305, a schedulebased negotiation module 330, a number of resources based negotiationmodule 340, and a price based negotiation module 350. A selection indexfunction 315 computes an index value 320 in order to make a resourceallocation decision.

The schedule based negotiation module 330 performs negotiation if a userrequesting the resources for a low priority task using the selectionindex function 315, a user demand 325, and a demand schedule 335. Theschedule based negotiation module 330 and/or the number of resourcesbased negotiation module 340 performs the negotiation if the userdemanding the resources for a medium priority task using the selectionindex function 315 and the user demand 325. The price based negotiationmodule 350 performs the negotiation if the user requesting resources fora high priority job utilizing the selection index function 315 and theuser demand 325. A user behavior coefficient 310 with respect to a usercan be computed to determine the degree of cooperativeness of the userwith other users. The value of user behavior coefficient 310 can beupdated each time it interacts with the system 300. The resourceallocation system 300 provides a Pareto optimal solution withoutimplementing market mechanisms and leads to high user satisfaction andretention rates.

FIG. 4 illustrates a high level flow chart of operation illustratinglogical operational steps of a method 400 for dynamically allocatingresources based on the multi-phase negotiation mechanism 360, inaccordance with the disclosed embodiments. Initially, a resourceallocation decision can be made based on an index value computed by aselection index function, as indicated at block 410. For example,consider n users that can be represented as (U₁, U₂ . . . , U_(x) . . ., U_(n)) and the corresponding demands at each time step can berepresented by ((d₁,d₂ . . . , d_(x) . . . , d_(n))¹, (d₁, d₂ . . . ,d_(x) . . . , d_(n))², . . . , (d₁,d₂ . . . , d_(x) . . . , d_(n))^(T)),wherein T is the total number of time steps. The resource allocationdecisions can be made by the system 300 based on the index values 320computed by the selection index function 315 as shown in equation (2)below:

$\begin{matrix}{{{SI}^{i}(x)} = \frac{{\begin{matrix}{{\alpha_{f}^{i}\left( {1 - \frac{w_{x}}{t}} \right)} + {\alpha_{\tau}^{1 - i}\left( {1 - \frac{d_{x}}{d_{\max}\mspace{11mu} }} \right)} +} \\{{\beta_{x}^{U}\left( {t - 1} \right)} + {\beta_{x}^{P}\left( {t - 1} \right)}}\end{matrix}{\beta_{x}^{S}\left( {t - 1} \right)}} +}{2}} & (2)\end{matrix}$

wherein the term

$\left( {1 - \frac{w_{x}}{t}} \right)$

introduces the notion of fairness which restricts the system 300 fromallocating the resources to same user repetitively and the term

$\left( {1 - \frac{d_{x}}{d_{\max}}} \right)$

introduces the notion of (high) system throughput. The definitions ofsymbol used in equation (2) are illustrated in Table 1.

TABLE 1 Symbol Definition α_(f) Fairness coefficient, α_(f) ∈ [0, 1]α_(t) Throughput coefficient, α_(t) ∈ [0, 1] β_(x) ^(S)(t-1) Avg.Behavior coefficient value for U_(x) for 1^(st) negotiation phase, at(t-1)^(th) time step β_(x) ^(U)(t-1) Avg. Behavior coefficient value forU_(x) for 2^(nd) negotiation phase, at (t-1)^(th) time step β_(x)^(P)(t-1) Avg. Behavior coefficient value for U_(x) for 3^(rd)negotiation phase, at (t-1)^(th) time step w_(x) Number of times U_(x)has won in past t Current trial number, t ∈ T T Total number of trialsd_(x) Demand of U_(x) d_(max) Maximum demand of user U_(i) ∈ U, max {d₁,d₂ . . . , d_(i) . . . , d_(n)}

A negotiation process can then be performed, as depicted at block 420. Auser requesting the resources for a low priority task can negotiatebased on schedule by considering the selection index function 315, auser demand 325, and a demand schedule 335, as illustrated at block 430.The first phase of negotiation starts with offering new schedule to eachuser. In this phase of negotiation, the tuple for selection index 315,user demand 325, and demand schedule 335 can be considered as(SI(x),d_(x),s_(x)) wherein Sl(_(x)) represents the selection indexvalue for U_(x), d_(x) represents the corresponding demand of the user,and s_(x) represents the user's demand schedule. The user's demandschedule can be explained as the number of resources required by a userwithin a specified time frame. In this step, the system 300 analyzes theactual schedule [(s₁ ^(I), s₂ ^(I) . . . , s_(x) ^(I) . . . , s_(n)^(I))]^(i) and offers [(s₁ ^(O), s₂ ^(O) . . . , s_(x) ^(O) . . . ,s_(n) ^(O))]^(i) as a new schedule, which can satisfy the demands of allusers. The scheduling can be done based on the selection index valuesand higher priority is given to higher Index value. The process isiterative where a new offer can be made at i^(th) time step if the userhadn't accepted the offer at (

t−1)

^(th) time step.

In i^(th) iteration {m:m≦n} is maximized wherein the users can berepresented as [(SI(1), d′₁, s₁ ^(F)), (SI(2), d′₂, s₂ ^(F)) . . . ,(SI(x), d′_(x), s_(x) ^(F)) . . . , (SI(m), d′_(m), s_(m) ^(F))]_(i)subject to

${{\sum\limits_{i = 0}^{m}d_{i}^{\prime}} \leq \frac{{\mathbb{R}}*\omega}{100}},$

wherein R represents the total available resources, ω representsallocation factor, and d′_(i) is the new demand of U_(i) correspondingto s_(i) ^(F). The value of ω can be determined according to the userdemand, i.e., if the user demand D>>R then the value of ω is more. Theuser behavior coefficient value for U_(x) at t^(th) time step of thisnegotiation phase is calculated as shown below in equation (3):

$\begin{matrix}{{{\overset{.}{\beta}}_{x}^{S}(t)} = \frac{s_{x}^{F} - s_{x}^{I}}{s_{x}^{O} - s_{x}^{I}}} & (3)\end{matrix}$

The term {dot over (β)}_(x) ^(s)(t) represents the user behaviorcoefficient value for U_(x) at t^(th) trial, which can be employed forcalculating average value of behavior coefficient for U_(x) at t^(th)trial i.e.

${\beta_{x}^{S}(t)} = \frac{\overset{t}{\sum\limits_{j = 1}}{{\overset{.}{\beta}}_{x}^{S}(j)}}{t}$

can be employed for calculating the selection index value for U_(x) at (

t+1)

^(th) trial. For example, assume the system 300 is able to successfullynegotiate with m_(s) users and the schedule at the end of the phase is{s₁ ^(F), s₂ ^(F) . . . , s_(x) ^(F) . . . , s_(m) ^(F)} and the usersare not considered in the following negotiation phases (i.e. β_(x)^(U)(t)=0, β_(x) ^(p)(t)=0 ∀ x ε m_(s)). Moreover, the behaviorcoefficient value of remaining (n-m₁S) users for this negotiation phaseis 0 i.e. β_(x) ^(s)(t)=0 ∀ x ∉ m_(s). The definitions of symbol used inequation (3) are illustrated in Table 2.

TABLE 2 Symbol Definition s_(x) ^(I) Original schedule of U_(x) s_(x)^(O) Schedule offered to U_(x) by system s_(x) ^(F) Final schedule ofU_(x) after negotiation ω Allocation factor decides % age of totalresources which could be allocated in this β_(x) ^(S)(t) Avg. behaviorcoefficient of U_(x) for 1st phase of negotiation

In subsequent time steps, the system 300 offers schedule which is closerto the actual schedule of the user and if the system is not able tosatisfy the demands of all users, then users with the lowest selectionindex value 320 can be removed from this phase of negotiation and theyare considered for negotiation in the next phase, where negotiation isdone based on the number of resources 340.

The negotiation can be performed based on schedule and the number ofresources by considering the selection index function 315 and the userdemand 325 if user demanding resources for medium priority task, asdepicted at block 440. The selection index 315 and user demand tuple 325can be represented as (SI(x),d_(x)), wherein SI(x) represents selectionindex value, and d_(x) represents the corresponding demand of the user.

The reduction factor, γ which determines the percentage reduction inusers' requirements, can be determined so that demands of all users (inthis phase) can be fulfilled. The value of γ is chosen in such a waythat minimum resource allocation quantity is equivalent to lowest unitof resource

${{i.e.\mspace{14mu} {\min\limits_{1 \leq x \leq n}\left( d_{x}^{\prime} \right)}} = r},$

where d′_(x) represents new demand of user calculated using reductionfactor and r represents lowest unit of resource (to be allocated). So,the resources offered to users in first iteration are

$\left\{ {\frac{\gamma*d_{1}}{100},{\frac{\gamma*d_{2}}{100}\mspace{14mu} \ldots}\mspace{20mu},{\frac{\gamma*d_{x}}{100}\mspace{14mu} \ldots}\mspace{14mu},\frac{\gamma*{\overset{.}{a}}_{m}}{100}} \right\}.$

It is also an iterative process where a new offer is made at i^(th) timestep if the user did not accept the previous offer at (

t−1)

^(th) time step.

In i^(th) iteration {m:m≦(n-m_(s))} is maximized where the users arerepresented as [(SI(1), d′₁), (SI(2), d′₂) . . . , (SI(x), d′_(x)) . . ., (SI(n-m_(s)), d′_((n-m) _(S) ))]^(i) subject to

${{\sum\limits_{i = o}^{m}d_{i}^{\prime}} \leq R},$

wherein R represents total available resources and d′_(i) is the newdemand of U_(i) calculated using reduction factor. The value of behaviorcoefficient for U_(x) at t^(th) trial is calculated as shown in equation(4) below:

$\begin{matrix}{{{\overset{.}{\beta}}_{x}^{U}(t)} = \frac{d_{x} - d_{x}^{\prime}}{d_{x}\left( {1 - \frac{\gamma}{100}} \right)}} & (4)\end{matrix}$

Term {dot over (β)}_(x) ^(U)(t) represents the user behavior coefficientvalue for U_(x) at t^(th) trial, which is employed for calculating anaverage value of the behavior coefficient for U_(x) at t^(th) trial i.e.

${\beta_{x}^{U}(t)} = \frac{\overset{t}{\sum\limits_{j = 1}}{{\overset{.}{\beta}}_{x}^{U}(j)}}{t}$

and it is used for calculating the selection index value for U_(x) at (

t+1)

^(th) trial. For example, assume the system 300 is able to successfullynegotiate with m_(u) users and their demand at the end of this phase is{d′₁,d′₂, . . . , d′_(x . . . , d′) _(m)} and these users are notconsidered in next negotiation phase i.e. β_(x) ^(p)(t)=0 ∀ x ε m_(U).Moreover, the behavior coefficient value for remaining (n-m₁U) users forthis negotiation phase is 0 i.e. β_(x) ^(U)(t)=0 ∀ x ∉ m_(U). Thedefinitions of symbol used in equation (4) are illustrated in Table 3.

TABLE 3 Symbol Definition d_(x) Original demand of usr d_(x)′ Demand ofU_(x) at the end of 2^(nd) phase of negotiation γ Reduction factor β_(x)^(U)(t) User behavior coefficient for 2^(nd) phase of negotiation

The system 300 enters into an iterative negotiation process with users,where subsequent iterations offers number of resources closer to actualuser demand. As discussed in the previous phase, if the system 300 isnot able to satisfy the demands of all users, then users with the lowestselection index value are removed from this phase of negotiation andthey are considered for negotiation in the next phase, where negotiationis done based on price of resources.

Finally, the negotiation can be performed based on per unit resourceprice by considering the selection index function 315 and the userdemand 325 if user requesting resources for high priority task, asindicated at block 450. The next phase of the negotiation processincludes negotiating on the basis of price of resources 350. In thisphase of negotiation process 350, the selection index 315 and userdemand tuple 325 is considered i.e. (SI(x),d_(x)p_(x)), wherein SI(x)represents selection index value, d_(x) represents the correspondingdemand of the user, and p_(x) represents the actual price of theresource. This phase begins with setting δ (i.e., cost factor), whichdetermines the new per unit price of the resource to be allocated tousers.

The value of δ is increased in each iteration and this process continuestill user demand is equal to total availability. With the increase inunit price in successive iterations, the users can reduce their demandand some can even reduce their demand to 0 (i.e., they quit thenegotiation process). For example, assume the value of δ at i^(th) timestep reaches a point, where the reduction of user demand is such thatthe total user demand becomes lesser than total availability ofresources

${{i.e.\mspace{14mu} {\sum\limits_{i = o}^{x}d_{i}^{\prime}}} < R},$

where x is the number of users in negotiation process after i^(th) timestep and R is the total availability of resources. In that case thevalue of δ is reduced to the value at (

t−1)

^(th) time step and higher priority is given to the users with highervalues of selection index during resource allocation.

In i^(th) iteration {m:m≦(n-m_(s)-m_(U))} is maximized where users arerepresented as [(SI(1), d′₁, p₁), (SI(2), d′₂, p₂) . . . , (SI(x),d′_(x), p_(x)) . . . , (SI(n-m_(s)-m_(U)), d′_((n-m) _(s) _(-m) _(U) ₎,p_((n-m) _(s) _(-m) _(U) ₎)]^(i) subject to

${{\sum\limits_{i = o}^{m}d_{i}^{\prime}} \leq R},$

wherein R represents the total available resources and d′_(i) representsthe new demand of U_(i) corresponding to new per unit price. The valueof behavior coefficient for U_(x) in t^(th) trial is calculated asindicated in equation (5) below:

$\begin{matrix}{{{\overset{.}{\beta}}_{x}^{P}(t)} = {\frac{\delta}{100}*\frac{d_{x}^{\prime}}{d_{x}}}} & (5)\end{matrix}$

Term {dot over (β)}_(x) ^(p)(t) represents user the behavior coefficientvalue for U_(x) at t^(th) trial, which is used for calculating averagevalue of behavior coefficient for U_(x) at t^(th) trial i.e.

${\beta_{x}^{P}(t)} = \frac{\overset{t}{\sum\limits_{j = 1}}{{\overset{.}{\beta}}_{x}^{P}(j)}}{t}$

and it is used for calculating the selection index value for U_(x) at (

t+1)

^(th) trial. For example, assume the system 300 is able to successfullynegotiate with m_(p) users and their demand at the end of this phase is{d′₁,d′₂, . . . , d′_(x) . . . , d′_(m)} and the behavior coefficientvalue for remaining (n-m_(p)) users is 0 i.e. β_(x) ^(p)(t)=0 ∀ x ∉m_(p). β_(x) ^(U)(t)=0 ∀ x ∉ m_(U). The definitions of symbol used inequation (5) are illustrated in Table 4.

TABLE 4 Symbol Definition d_(x) Original demand of user d_(x)′ Demand ofU_(x) at the end of 3^(rd) phase of negotiation δ Cost factor β_(x)^(P)(t) User behavior coefficient for 3^(rd) phase of negotiation

The users with low values of the behavior coefficient are considered asgreedy users and those with high values are considered as cooperativeusers. The greedy users tend to be less flexible in the negotiationprocess, while cooperative users are more flexible in the negotiationprocess. As a result, cooperative users lead to a more efficientresource allocation process and in order to motivate users to be morecooperative, the behavior coefficient value is assigned to each userdepending on the behavior. The users with higher values of behaviorcoefficient (i.e., cooperative users) can have higher probability ofselection in future interactions as compared to users with lower valuesof behavior coefficient (i.e., greedy users). The multi-phasenegotiation mechanism 360 motivates the users to be cooperative amongthem and improves a cooperative behavior coefficient and an overall usersatisfaction rate, as shown at block 460.

The multi-phase negotiation mechanism 360 offers an efficient solutionto the resource allocation problems which aims at increasing the user'ssatisfaction rate. The effectiveness of the multi-phase negotiationmechanism 360 can be tested in scenarios where D>>R, wherein D is totaluser demand and R is the total resource availability. The multi-phasenegotiation mechanism 360 encourages the users to be cooperative amongthem using one of the three negotiation mechanisms according to theirpriority of tasks. The resource allocation system 300 increase the usersatisfaction rate and motivates the users to be more cooperative amongthem which results in the overall increase in user's satisfaction rate.The increase in the user satisfaction leads to higher user retentionwhich in turn increases the ACS's revenue.

FIGS. 5-6 illustrate a graph 500 and 600 depicting data indicative ofpercentage satisfied users, in accordance with the disclosedembodiments. The user satisfaction with respect to the allocation method400 is compared with different allocation approaches, for example, evendistribution 510, highest priority first 520, first come first serve530, and fair allocation 540. The user satisfaction rate is directlyproportional to throughput of an algorithm as higher is the number ofsatisfied users more is the retention rate. As the user waiting time isinversely proportional to the fairness of an algorithm the lower is thewaiting time for the user (for getting a resource) the more is thefairness. The test case scenarios for analyzing the user satisfactionrate and user waiting time in different resource allocation algorithmsare illustrated in TABLE 5.

TABLE 5 # # Min. Max. Test Case Resources Users Demand/User Demand/User# Trials Case 1 100 50 1 60 100 Case 2 100 50 1 10 100

FIGS. 5-6 illustrate the user satisfaction rates for case 1 and case 2respectively. The user satisfaction rate in FIG. 6 is more than previouscase because the maximum demand of a single user can be 10 and totalresource availability is 100. Table 6 shows the average statistics forthe user satisfaction rate in the test scenarios.

TABLE 6 Avg. Avg. % Avg. Avg. % Satisfied Dissatisfied SatisfiedSatisfied Dissatisfied Satisfied Algorithm Case 1 Case 2 EvenDistribution 1.68 48.32 3.36% 10.65 39.35 21.3% First Come First 5.5444.46 11.08% 19.56 30.44 39.12% Serve Highest Priority 2.3 47.7 4.6%11.31 38.69 22.62% First Fair Allocation 11.56 38.44 23.12% 28.59 21.4157.18% Our Proposed 15.41 34.59 30.82 39.11 10.89 78.22% Method

The analysis of the satisfaction rates on the basis of above statisticsimplies that the percentages of satisfied users are more in theallocation method 400 as compared to other approaches. The fairnesscomponent of the resource allocation approach 400 i.e.

$\left( {1 - \frac{w_{x}}{t}} \right)$

accounts for higher user satisfaction rate and at the same timethroughput component balances it depending on the value of throughputcoefficient, thus achieving optimal fairness and throughput in theresource allocation.

FIGS. 7-8 illustrate graphs 700 and 800, which depict data indicative ofuser waiting time, in accordance with the disclosed embodiments. Tables7 and 8 respectivley correspond to Test cases 1 and 2 respectively.

TABLE 7 Min Wait Max Wait Avg. Wait Std. Dev. Algorithm Time Time TimeWait Time Even Distribution 0 99 26.42 14.69 FCFS 0 99 25.29 21.96 HPF 082 19.97 8.72 Fair Allocation 0 24 3.22 0.4 Our Proposed 0 21 2.2 0.28Method

TABLE 8 Min Wait Max Wait Avg. Wait Std. Dev. Algorithm Time Time TimeWait Time Even Distribution 0 38 3.68 0.94 FCFS 0 99 28.29 36.76 HPF 024 3.47 0.9 Fair Allocation 0 8 0.74 0.09 Our Proposed 0 5 0.28 0.04Method

The users' waiting time in case of the allocation method 400 is muchless than other approaches which implies the resource allocation method400 is comparatively fairer. The user's waiting time with respect to theallocation method 400 is compared with different allocation approaches,for example, highest priority first 520 and fair allocation 540.

FIGS. 7-8 illustrate the total waiting time for users is lesser in theallocation method 400 as compared to the highest priority first 520 andthe fair allocation 540 for both scenarios. This signifies thatdeviation between users' waiting time in case of the resource allocationmethod 400 is lesser than traditional resource allocation method 520 and540 and it guarantees envy free allocation.

It will be appreciated that variations of the above-disclosed and otherfeatures and functions, or alternatives thereof, may be desirablycombined into many other different systems or applications. Also, thatvarious presently unforeseen or unanticipated alternatives,modifications, variations or improvements therein may be subsequentlymade by those skilled in the art which are also intended to beencompassed by the following claims.

What is claimed is:
 1. A method for dynamically allocating resources ina process, said method comprising: computing a behavior coefficient withrespect to a particular user to determine a degree of cooperativeness ofsaid user with respect to a plurality of other users; performing anegotiation process utilizing at least one negotiation mechanism inresponse to a request for a resource; and dynamically allocating saidresource in a process with a high user satisfaction and a retention ratebased on said behavior coefficient, said negotiation process, and saidat least one negotiation mechanism.
 2. The method of claim 1 furthercomprising rendering a resource allocation decision with respect to saidprocess based on an index value computed via a selection index function.3. The method of claim 1 further comprising configuring said negotiationmechanism to include at least one of the following types of negotiationprocesses: a schedule based negotiation process; a number of resourcesbased negotiation process; and a price based negotiation process.
 4. Themethod of claim 3 further comprising performing said schedule basednegotiation process if said request for said resource comprises arequest for a low priority task by considering a selection index, a userdemand, and a demand schedule tuple.
 5. The method of claim 4 furthercomprising: analyzing an actual schedule and offering a new schedule tosatisfy said user demand and provide a higher priority to a higher indexvalue; determining a total available resource value based on said userdemand and offering a schedule that is closer to said actual schedule ofsaid user in a subsequent time step; and removing said user with alowest selection index value and thereafter consider said user with saidlowest selection index value for said number of resources basednegotiation process if said user demand is not satisfied.
 6. The methodof claim 3 further comprising performing said schedule based negotiationprocess and/or said number of resources based negotiation if saidrequest for said resource comprises a request for a medium priority taskby considering said selection index and said user demand tuple.
 7. Themethod of claim 6 further comprising: determining a reduction factorthat determines a percentage reduction in said user requirement in orderto fulfill said user demand wherein said reduction factor value ischosen in such a way that a minimum resource allocation quantity isequivalent to a lowest unit of resource; entering into an iterativenegotiation process with said user wherein a subsequent iteration offersa number of resources closer to an actual user demand; and removing saiduser with said lowest selection index value and thereafter consider saiduser with said lowest selection index value for said price basednegotiation process if said user demand is not satisfied.
 8. The methodof claim 1 further comprises performing said price based negotiationprocess if said user request for said resource comprises a request for ahigh priority task by considering said selection index and said userdemand tuple.
 9. The method of claim 8 further comprising: setting acost factor that determines a new per unit price of said resource to beallocated and thereafter increase said cost factor value in eachiteration until said user demand is equal to a total availability; andconsidering said user with a low value of said user behavior coefficientas a greedy user and said user with a high value as a cooperative userwherein said greedy user tends to be less flexible in said negotiationprocess and said cooperative user is more flexible in said negotiationprocess.
 10. The method of claim 9 further comprising assigning saiduser behavior coefficient value to each user depending on said behaviorin order to motivate said user to be more cooperative for efficientlyallocating said resource.
 11. The method of claim 9 wherein saidcooperative user possesses a higher probability of selection in a futureinteraction as compared to said greedy user.
 12. A system fordynamically allocating resources in a process, said system comprising: aprocessor; and a computer-usable medium embodying computer code, saidcomputer-usable medium being coupled to said data bus, said computerprogram code comprising instructions executable by said processor andconfigured for: computing a behavior coefficient with respect to aparticular user to determine a degree of cooperativeness of said userwith respect to a plurality of other users; performing a negotiationprocess utilizing at least one negotiation mechanism in response to arequest for a resource; and dynamically allocating said resource in aprocess with a high user satisfaction and a retention rate based on saidbehavior coefficient, said negotiation process, and said at least onenegotiation mechanism.
 13. The system of claim 12 wherein saidinstructions are further configured for rendering a resource allocationdecision with respect to said process based on an index value computedvia a selection index function.
 14. The system of claim 12 wherein saidinstructions are further configured for modifying said negotiationmechanism to include at least one of the following types of negotiationprocesses: a schedule based negotiation process; a number of resourcesbased negotiation process; and a price based negotiation process. 15.The system of claim 14 wherein said instructions are further configuredfor performing said schedule based negotiation process if said requestfor said resource comprises a request for a low priority task byconsidering a selection index, a user demand, and a demand scheduletuple.
 16. The system of claim 15 wherein said instructions are furtherconfigured for: analyzing an actual schedule and offering a new scheduleto satisfy said user demand and provide a higher priority to a higherindex value; determining a total available resource value based on saiduser demand and offering a schedule that is closer to said actualschedule of said user in a subsequent time step; and removing said userwith a lowest selection index value and thereafter consider said userwith said lowest selection index value for said number of resourcesbased negotiation process if said user demand is not satisfied.
 17. Thesystem of claim 14 wherein said instructions are further configured forperforming said schedule based negotiation process and/or said number ofresources based negotiation if said request for said resource comprisesa request for a medium priority task by considering said selection indexand said user demand tuple.
 18. The system of claim 17 wherein saidinstructions are further configured for: determining a reduction factorthat determines a percentage reduction in said user requirement in orderto fulfill said user demand wherein said reduction factor value ischosen in such a way that a minimum resource allocation quantity isequivalent to a lowest unit of resource; entering into an iterativenegotiation process with said user wherein a subsequent iteration offersa number of resources closer to an actual user demand; and removing saiduser with said lowest selection index value and thereafter consider saiduser with said lowest selection index value for said price basednegotiation process if said user demand is not satisfied.
 19. Aprocessor-readable medium storing code representing instructions tocause a processor to perform a process for dynamically allocatingresources in a process, said code comprising code to: compute a behaviorcoefficient with respect to a particular user to determine a degree ofcooperativeness of said user with respect to a plurality of other users;perform a negotiation process utilizing at least one negotiationmechanism in response to a request for a resource; and dynamicallyallocate said resource in a process with a high user satisfaction and aretention rate based on said behavior coefficient, said negotiationprocess, and said at least one negotiation mechanism.
 20. Theprocessor-readable medium of claim 19 wherein said code furthercomprises code to render a resource allocation decision with respect tosaid process based on an index value computed via a selection indexfunction.